[release/7.0] [QUIC] Fix native crashes and heap corruption via "generated-like" interop #75192
Conversation
…terop (dotnet#74669) * Send buffers and handles crash fixes * Add generated-like interop * Apply PR feedback from dotnet#74611 * Change asserts * Feedback + moved native methods to their own file * PR feedback Co-authored-by: ManickaP <mapichov@microsoft.com>
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackport of #74669 to release/7.0 /cc @CarnaViire Customer ImpactHTTP/3 or QUIC application crashed with either "Aborted" or "Segmentation Fault" due to native heap corruption. The native crash happened in a time frame from several minutes to several hours, depending on how common was the race between Dispose and other QUIC calls (e.g. cancelling/disposing the stream while sending the data) in the user scenario. The root cause of the native heap corruption was incorrect and unsynchronized usage of native pointers and arrays, which in case of multithreaded access led to use-after-free and other native memory access issues. This eventually led to native heap corruption which manifested as a crash after some time. There are 2 main parts of the fix:
Discovered in HTTP/3 stress runs. TestingMultiple 10+ hours of stress test runs. RiskLow, System.Net.Quic is still in preview.
|
|
@danmoseley need an approval please. |
|
approved - basic stability of new feature |
|
BTW @CarnaViire great to see us using stress testing to validate in this way. Nice |
|
Happens on |
|
/azp run runtime-libraries stress-http |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Approved, signed off, and CI is green. Ready to merge. |
Backport of #74669 to release/7.0
Fixes #72696
/cc @CarnaViire
Customer Impact
HTTP/3 or QUIC application crashed with either "Aborted" or "Segmentation Fault" due to native heap corruption. The native crash happened in a time frame from several minutes to several hours, depending on how common was the race between Dispose and other QUIC calls (e.g. cancelling/disposing the stream while sending the data) in the user scenario.
The root cause of the native heap corruption was incorrect and unsynchronized usage of native pointers and arrays, which in case of multithreaded access led to use-after-free and other native memory access issues. This eventually led to native heap corruption which manifested as a crash after some time.
There are 2 main parts of the fix:
Discovered in HTTP/3 stress runs.
Testing
Multiple 10+ hours of general HTTP/3 stress test runs, multiple ~3h runs for targeted stress scenario with high race probability (POST Duplex Dispose with cancel rate 100%).
Before the fix, the issue would almost always manifest in ~1h timeframe for general HTTP/3 stress test run, and in ~5min for targeted stress scenario.
Risk
Low, System.Net.Quic is still in preview.